🟡 [Medium] New AVX512 k2 noise path uses large unconditional stack buffers, unlike its AVX2 sibling
💡 SUGGEST convention

mlkem_get_noise_k2_avx512 declares byte rand[8 * PRF_RAND_SZ] (PRF_RAND_SZ = 2*SHA3_256_BYTES = 272, so 2176 bytes) as a plain fixed stack array, and its helper mlkem_get_noise_x8_eta3_avx512 (and the eta2 helper) each declare word64 state[25 * 8] (1600 bytes) on the stack. The corresponding AVX2 sibling mlkem_get_noise_k2_avx2 instead respects WOLFSSL_SMALL_STACK via WC_DECLARE_VAR(rand, byte, 4 * PRF_RAND_SZ, 0) + WC_ALLOC_VAR_EX(...), and the new AVX512 matrix generators (mlkem_gen_matrix_k2/k3/k4_avx512) also use the XMALLOC small-stack pattern. So the new k2 noise path both doubles the buffer and drops the small-stack handling its own AVX2 twin provides, violating the project rule that large (>~100 byte) stack buffers use the WOLFSSL_SMALL_STACK pattern. Practical impact is low because these paths only execute on AVX-512-capable x86-64 (rarely a small-stack target), but it is an internal inconsistency worth aligning.

Suggestion: Use the WC_DECLARE_VAR / WC_ALLOC_VAR_EX pattern (as mlkem_get_noise_k2_avx2 does) for the rand and state buffers in mlkem_get_noise_k2_avx512 and the x8 helpers, returning MEMORY_E on allocation failure. Note k3/k4 avx512 mirror their avx2 siblings' plain-stack arrays, so this concern is specific to the k2 path.